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METHOD FOR MODELING HARDWARE USING SOFTWARE 

Background 

This invention relates to software programs and, more particularly, to 
application programming interfaces. 

Software development is a robust industry. Following the development of 
5 new hardware, software typically provides an interface to the hardware. 

Before writing a software program, a developer may need to understand 
the functional requirements of the software, the hardware upon which the 
software may operate, and the operating environment. Particularly for complex 
software, a logical organization of the software may also be beneficial to 
10 reducing defects. 

Some software programs are structured so that they work in a variety of 
operating environments. Additionally, software that is well-written anticipates 
new hardware to be supported by the software program. An application 
programming interface, or API, is a tool for structuring such software 
15 applications. As the name suggests, the API "interfaces" the core application 
code with the rest of an operating environment. 

APIs generally include specifications or protocols for their use. Programs 
written according to the protocol may have a similar interface to the end-user, 
for example. APIs also may include routines, libraries, or other tools which 
20 minimize duplicity of effort for various developers who may perform similar 
functions. Thus, APIs are tools that typically permit new development to support 
new operating systems, to support new hardware, or to add new software 
features to existing application programs. 
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Software which supports a number of hardware components may benefit 
from such interfaces. Further, software which supports hardware from more 
than a single vendor, each with a distinct hardware requirement, may interface 
to an API to simplify code development. For projects where the hardware is 
5 available only after the software Is written, an API may also promote developing 
the software within the project time constraints. 

Thus, there is a continuing need for an interface between a plurality of 
hardware devices and a software program to support the hardware devices such 
P that the software program Is simplified while continuing to support the hardware. 

: 5*1 

:f 10 Summary 

m In general. In one embodiment of the invention, a method comprises 

I"; i 

defining a plurality of hardware devices as a plurality of objects, providing a 
plurality of tools to perform a plurality of operations on the plurality of objects, 

M executing a software program to use the tools and responding to the plurality of 

m 15 operations by the plurality of hardware devices. 

:| Other features and embodiments will become apparent from the following 

^6 description, the drawings, and from the claims. 

Brief Description of the Drawings 
Figure 1 Is a block diagram of an object model API according to one 
20 embodiment of the Invention; 

Figure 2 is a block diagram of an object of the object model API according 
to one embodiment of the invention; 

Figure 3 is a block diagram of the configuration library of the object model 
API according to one embodiment of the invention; 
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Figure 4 is a blocic diagram of the RAID API according to one embodiment 
of tine invention; 

Figure 5 is a block diagram of RAID hardware in accordance with one 
embodiment of the invention; 
5 Figure 6 is a block diagram of a plurality of RAID objects for the RAID 

hardware of Figure 5 in accordance with one embodiment of the invention; 

Figure 7 is a block diagram of the controller object in accordance with one 
embodiment of the invention; 

Figure 8 is a block diagram of the bus object in accordance with one 
■O 10 embodiment of the invention; 

m Figure 9 is a block diagram of the disk object in accordance with one 

m embodiment of the invention; 

j{ Figure 10 is a block diagram of the array object in accordance with one 

;! embodiment of the invention; 

j=y 15 Figure 11 is a block diagram of the volume object in accordance with one 

\^ embodiment of the invention; and 

5 Figure 12 is a flow diagram of a bus scan operation using the RAID object 

API in accordance with one embodiment of the invention. 

Detailed Description 

20 In the prior art, a software program may be written to support one or 

more hardware devices. For example, the software program may include a 
graphical user interface which permits a user of the software program to control 
or monitor the hardware devices. The software program may Initialize the 
hardware devices, as another example. 

25 In supporting the hardware device, the software program may directly 

interact with the hardware device, or instead interact with an interface to the 
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hardware. The interface to the hardware device may itself be a second software 
program. 

The software program may be written to support hardware devices from a 
particular vendor. In order to support hardware devices from a second vendor, 
5 the software program may be changed, the second vendor's hardware device or 
an interface to the second vendor's hardware device may be changed. For each 
distinct hardware type supported by the software program, the software 
program may grow proportionately. 

An object model application programming interface (API) 10 may provide 

10 an alternative to the prior art. Turning to Figure 1, the object model API 10, 
according to one embodiment of the invention, may include a configuration 
library 20 and a plurality of objects 30. The object model API 10 is coupled 
between a software program 12 and a hardware device 16, a hardware device 
17, and a hardware device 18. 

15 The hardware device 16 may, for example, be supplied by a different 

vendor than the hardware device 17, etc. The hardware device 16 may itself 
include software, such as a software interface (not shown). The hardware 
device 16 may operate using one protocol, the hardware device 17 may operate 
using a second protocol, and so on. 

20 The object model API 10 may reside between the software program 12 

and the hardware devices 16-18. In one embodiment of the invention, the 
object model API 10 provides the capability to abstract the hardware devices 16- 
18 so that the software program 12 need not be written with the distinct 
requirements of the hardware devices 16-18 in mind. Instead, the software 

25 program 12 communicates with the objects 30 which model the hardware 
devices 16-18. In turn, the hardware devices 16-18 communicate with the 
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object model API 10, whether to take actions, provide information, or perform 
other operations on the hardware devices 16-18. 

The object model API may be beneficial for some hardware/software 
models. The software program 12 may be written with less than full knowledge 
5 of the particular hardware involved. Instead, using the object model API 10, the 
software program 12 may be written once a "model" of the hardware devices 16- 
18 has been defined. The objects 30 represent this model. 

Each hardware device 16-18 to be supported by the software program 12 
communicates with the object model API 10. Where the hardware devices 16-18 
10 include a software interface, the interface may communicate with the object 
m model API 10. For example, the interface to the hardware devices 16-18 may 

ifl respond to commands from the object model API 10 such that the commands 

^ are executed upon the hardware devices 16-18. 

As part of the object model API 10, the configuration library 20 includes a 
j=y 15 set of tools which enable the software program 12 to communicate with the 
j{j objects 30. The objects 30 model the hardware devices 16-18. Once the 

software program 12 knows how to retrieve and manipulate the objects 30, 
using the tools from the configuration library 20, the software program 12 may 
perform operations on the objects 30. 
20 The objects 30, in essence, define the hardware devices 16-18 by 

modeling the operations (or methods), the attributes (or properties), and the 
actions (or events) of each hardware device 16-18. An operation, known as a 
method, may be invoked upon an object. The method is appropriate for the 
real-world hardware modeled by the object. One or more attributes, described 
25 below as properties, may also be used to define an object. Actions, described 
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below as events, may model real-world occurrences by the hardware devices IS- 
IS. 

In one embodiment of the invention, each object encapsulates the 
operations of, the attributes of, and the actions to be taken upon the real-world 
5 hardware modeled by the object. For example, the hardware device 16 may be 
divided into components, each of which is modeled as a separate object 30. The 
characteristics for each component are identified, and become properties and 
methods of the object 30. Likewise, hardware devices 17 and 18 may have 
objects 30 for modeling their components. 

10 In Figure 2, in one embodiment of the invention, the object 30 Includes 

methods 32, properties 34 and events 36 for representing the characteristics of 
the hardware devices 16-18 modeled by the object 30. The methods 32 may 
include functions or actions which the hardware devices 16-18 modeled by the 
object 30 may perform. 

15 For example, suppose the hardware device modeled is a staple gun. A 

staple gun may push staples into a piece of paper. Accordingly, an object 
modeling the staple gun may appropriately include a method, PushStaples. 

The properties 34 may include attributes of the hardware device 16. For 
example, attributes of the staple gun may include the number and type of 

20 staples. An object modeling the staple gun may appropriately include two 
properties, NumberOfStaples and StapleType. 

Further, the properties 34 may be defined as having different types. In 
the staple gun example, NumberOlStaples may be represented as an integer 
type, while StapleType may be a Boolean variable. 

25 The events 36 may include those behaviors of the hardware devices 16-18 

for which notification may be requested. For example, the staple gun may run 
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out of staples. Accordingly, an object modeling the staple gun may appropriately 
include an event, OutOfStaples. 

The methods 32, the properties 34, and the events 36 of the object 30 
thus model the behavior of the hardware devices 16-18. Once the hardware 
5 devices 16-18 are defined in terms of these features, the software program 12 
may communicate with the object 30 instead of the hardware devices 16-18. In 
turn, the hardware devices 16-18 communicate with the object model API 10. 

In one embodiment of the invention, the configuration library 20 may be 
used to communicate with the objects 30. In Figure 3, the tools of the 
'0 10 configuration library 20 may include several functions. The functions may be 
ill used by the software program 12 to communicate with the objects 30. 

m The configuration library 20 includes an initialization function 52. The 

initialization function 52 initializes the configuration library 20. In one 
embodiment of the invention, the initialization function 52 is executed prior to 
ry 15 any other function in the configuration library 20. 

A second initialization function 54 allows the software program 12 to 
override any memory management functions of the environment. Some system 
management architectures provide unique memory management routines. 
Under such system management architectures, memory management routines 
20 may be replaced with other routines. The second initialization function 54 thus 
overrides the memory manager upon command. 

The configuration library 20 further includes a set of functions for object 
creation and object discovery. An object locating function 58 provides the 
capability to locate an object of a specific type with a specific property value 
25 using a comparison operator as an input value. The object locating function 58 
may be used to determine the components of the hardware device 16 by the 
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software program 12, for example. Closely associated with the object locating 
function 58, a subsequent object locating function 60 provides the capability to 
locate the next object based upon the parameters provided in the object locating 
function 58. 

In one embodiment of the invention, an object creation function 56 allows 
the software program 12 to create an object for the hardware devices 16-18 
which may not be physically located, e.g., virtual hardware features. The object 
creation function 56 essentially creates an internal storage area for the object 
30. The internal storage area may be used for the properties 34 of the object 30 
used to represent the virtual hardware feature, for example. 

Another tool in the configuration library 20, a method invocation function 
62, allows the software program 12 to execute or invoke a method 32 within an 
object 30. The method 32 may include parameters which may be set prior to 
invoking the method 32 or may be returned upon executing the method 32. In 
one embodiment of the invention, the parameters may include properties 34 of 
the object 30 for which the method 32 is invoked. 

In one embodiment of the invention, the configuration library 20 also 
provides functions for manipulating the properties 34 of the object 30. A get 
property function 64 enables the sofb/vare program 12 to retrieve the property 
34 of the object 30. Likewise, a set property function 66 allows the software 
program 12 to set the property 34 of the object 30. 

The configuration library 20 also provides functions which enable the 
software program 12 to be notified when an event to one of the hardware 
devices 16-18 occurs. A monitor event function 68, when enabled, allows the 
software program 12 to be notified upon the occurrence of the particular event 
36 of the object 30. Likewise, a monitor event off function 70 allows the 
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software program 12 to turn off monitoring of the particular event 36 of the 
object 30. 

Thus, in one embodiment of the invention, the configuration library 20 of 
the object model API 10 provides the capability to invoke the methods 32, set 
5 and retrieve the properties 34, and monitor the events 36 for a given object 30. 
The software program 12 may utilize the functions in the configuration library 20 
to communicate with the objects 30 which model the hardware devices 16-18. 

The object model API 10 may be used as a front end to a variety of types 
of hardware devices 16-18. By distilling the hardware devices 16-18 into distinct 
10 components, an object model 30 for each component may then be created. Like 
the staple gun, described above, a variety of hardware devices may then be 
defined In terms of operations (methods), attributes (properties) and actions 
(events). These methods 32, properties 34, and events 36 are then 
encapsulated as objects 30. To support the hardware devices 16-18, a 
15 developer may then use the functions of the configuration library 20, described 
above, to perform operations upon the objects 30. 

Because the software program 12 does not communicate directly with the 
hardware devices 16-18, the requirements of the hardware devices 16-18 are 
unimportant to the software program 12. Instead, the software program 12 
20 communicates with the objects 30 using the tools of the configuration library 20. 
In this way, the software program 12 may support the hardware devices 16-18, 
even when the hardware devices 16-18 change. Further, the software program 
12 may support future hardware additions. 

Software which supports a redundant array of independent disks, or RAID, 
25 system, may benefit from the object model API 10. A RAID system is essentially 
a collection of disks, connected by one or more buses, and employing one or 
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more controllers. RAID systems may employ one or more disk drives, typically to 
provide fault tolerance and to enhance performance. In addition to the disl< 
drives themselves, the RAID system may include a plurality of controllers and 
buses. Further, the RAID system may be organized into physical representations 
5 of disl<s, called arrays, or logical representations of disks, called volumes. The 
RAID hardware, as well as its supporting software, may therefore be complex. 

Turning to Figure 4, a particular implementation of the object model API 
10, shown as a RAID object API 10a, includes the configuration library 20 and 
RAID objects 30a, in accordance with one embodiment of the invention. The 
'0 10 RAID API 10a interfaces with a RAID software program 12a and a RAID 
m hardware device 16a, a RAID hardware device 17a, and a RAID hardware device 

m 18a. 

As in Figure 1, the RAID hardware devices 16a-18a may include RAID 
hardware device 16a, from one vendor, RAID hardware 17a, possibly from a 
jij 15 second vendor, and RAID hardware 18a, possibly from a third vendor. Each 
ifl RAID hardware device 16a-18a may include a software interface (not shown). 

S The RAID hardware devices 16a-18a are responsive to directives from the RAID 

API 10a. Likewise, the RAID software 12a communicates with the objects 30a 
modeling the RAID hardware devices 16a-18a using the configuration library 20. 
20 As with the object model API 10, with the RAID API 10a, RAID objects 

30a may be defined according to the RAID hardware devices 16a-18a. The RAID 
hardware devices 16a-18a may also be described in terms of physical groupings 
of disks into a unified storage medium, known as an array. Alternatively or 
additionally, the RAID hardware devices 16a-18a may be described in terms of 
25 logical groupings, or volumes. 



The RAID hardware 16a-18a may be distilled into distinct components, 
which are then modeled as objects 30a. In Figure 5, a system 14 according to 
one embodiment of the invention may include a processor 90 and a memory 92 
are coupled to a processor bus 94. A secondary bus 98 may be coupled to the 
processor bus 94 via a bridge 96. 

The RAID hardware devices 17a extend from the secondary bus 98, in 
one embodiment of the invention. Controllers lOOA and lOOB are coupled to the 
secondary bus 98. From the controllers 100, a small computer system interface, 
or SCSI, bus llOA and a SCSI bus HOB connect the controllers lOOA and lOOB 
to a plurality of disks 120. For example, disks 120A, 1208, 120C and 120D are 
coupled to the SCSI bus 11 OA. 

As stated above, the RAID system may be organized into physical 
representations of disks, called arrays, or logical representations of disks, called 
volumes. In one embodiment of the invention, the volumes may be repositories 
for information about the volume, while the arrays store no information. So, for 
example, information about a volume may be written on the volume itself. The 
array has no such storage capability. 

In Figure 5, the RAID hardware devices 17a include a plurality of arrays 
130. For example, disks 120C and disks 120D are joined to form array 130B. In 
one embodiment of the invention, each array 130 has at least one volume 140 
associated with the array 130. In Figure 5, the array 130D includes two volumes 
140E and 140F. However, array 130B includes only a single volume 140D. 

The RAID hardware devices 17a may be presented in a number of 
different ways. For example, in Figure 5, the controllers lOOA and lOOB extend 
from the same secondary bus 98. Alternatively, these controllers 100 may 
extend from distinct buses. 
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From the physical RAID hardware devices 17a of Figure 5, a plurality of 
RAID objects 30a may be derived. In Figure 6, the RAID objects 30a include 
controller objects 100, bus objects 110, disk objects 120, array objects 130, and 
volume objects 140. 

Each of the RAID objects 30a of Figure 6 represents a component of the 
RAID hardware devices 17a in Figure 5. For example, the RAID hardware 
devices 17a include eight disks 120A-120H. Thus, the RAID objects 30a include 
eight disk objects 120a-120h. Likewise, the RAID hardware devices 17a include 
two controllers lOOA and lOOB. Accordingly, in Figure 6, controller object 100a 
and 100b are two of the RAID objects 30a. The RAID objects 30a thus 
represent, using objects, the entire configuration of the RAID hardware devices 
17a. 

In one embodiment of the invention, each of the RAID objects 30a 
inciuSes-jTiethods 32, properties 34 and events 36, which are consistent with the 



particular haroWace features these objects 30a model. In Figure 7, for example, 
the controller object itJOso^des a method 102, used to reset the controller of 
the RAID hardware devices 17a>-Ukewise, the controller object 100 includes 
properties 34, such as a bus counting metFibd403, used to report the number of 
buses on the controller, and a disk counting rnelhod 104, for reporting the 
number of disks on the controller. Each of the properties 34s5accessible to the 
RAID software 12a for communicating with the controller of the RXiBvJwdware 
devices 17a. ^ 

In Figure 8, the bus object 110 includes a scan bus method 111 and 
several properties 34, including a bus indexing property 112, a bus identification 
property 113, a bus protocol property 114, a bus device count property 115 and 
a Boolean property 116, which tells whether the bus is presently scanning. As 
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with the controller object 100, the bus object 110 includes no events for the 
RAID software 12a to monitor. However, the RAID software 12a may set or 
retrieve any of the properties or may invoke the scan bus method 111, as 
desired. 

5 In Figure 9, the disk object 120 includes methods 32, properties 34, and 

events 36 which allow the RAID software 12a to communicate with the plurality 
of disks, such as the eight disks 120A-120H of Figure 5. For example, a method 
122, a method 125, and a method 126 may be used to mark a disk as normal, 
offline, and online, respectively. A total block count property 153 may be used 
10 to retrieve the total block count of the disk. 

In addition to several methods 32 and properties 34, the disk object 120 
includes events 36 which may permit the RAID software 12a to monitor the 
behavior of each disk modeled by the disk object 120. For example, a disk is 
normal event 161 may permit the RAID software 12a to be notified when the 
15 disk has been marked as normal (following the invocation of the mark as normal 
method 122). Recall that the configuration library 20 provides two functions, 
event monitor on 68 and event monitor off 70, which allow the RAID software 
12a to monitor one or more events 36 of the disk object 120. 

In Figures 10 and 11, the array object 130 and the volume object 140, 
20 like the^isl^^ject 120, include methods 32, properties 34 and events 36. In 
one embodimenToftheJiTvention, the array is defined as a physical grouping of 
(^one or more disks. Accordin^t^triljearray object 130 includes a method 131 to 
y create an array and a method 132 to expand^^^^ray. A disk count property 
^ 134 enables the RAID software 12a to identify themiiiib^of disks 120 included 
25 in the array 130. A volume degraded event 169 .permits the'MID software 12a 
to receive notification when a volume 140 of ttie^array 130 has degrac 
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The volume object 140 (Figure 11) includes methods such as a method 
141 and a method 142, for creating and deleting a volume 140, respectively, 
from the RAID hardware devices 17a. Properties such as number of bytes per 
block 171 and total number of blocks 172 provide other indicia about the volume 
140. The volume object 140 further includes event notification for failed, 
migrating, and initializing volumes, an event 181, an event 182, and an event 
183, respectively. 

Using the above objects in conjunction with the functions of the 
configuration library 20, the RAID software 12a may perform a number of 
operations on the RAID hardware devices 17a. Simply by controlling the 
properties 34 and methods 32 of the RAID objects 30a, the RAID software 12a 
can configure the RAID hardware devices 17a. 

As an example, the RAID software 12a may perform an operation to 
determine the devices which are located on a bus. Looking back to Figure 5, 
suppose the RAID software 12a wants to determine which devices are connected 
to the SCSI bus UOA of the system 14. An operation to scan the SCSI bus UOA 
according to one embodiment of the invention includes invoking the method 
invocation function 62 of the configuration library 20 (see Figure 3). In Figure 
12, the method invocation function 62 is passed two parameters (block 202). 
The object 30 for which a method 32 is invoked is provided as a parameter. In 
the RAID objects 30a, the available objects are controller objects 100, bus 
objects 110, disk objects 120, array objects 130, and volume objects 140. To 
scan the SCSI bus UOA, the bus object UOa is passed as a parameter. The 
method 32 to invoke from the passed object is also provided as a parameter. 

Looking back to Figure 8, the scan bus method 111 is the only method 32 
available for the bus object 110, and is the desired method for performing a scan 
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operation upon the SCSI bus UOA. Accordingly, the method invocation function 
62 is invoked, and the bus object 110 and the scan bus method 11 are passed as 
parameters (block 202). 

The get property function 64 is next invoked (block 204). The get 
property function 64 is passed three parameters: the object for which a property 
is to be retrieved, the property to be retrieved, and a location for storing the 
property value. As with the method Invocation function 62, the bus object 110 is 
passed as a parameter. Also, the bus is presently scanning property 116, and a 
memory location for storing the result, are passed as parameters. The property 
116 returns a Boolean result. 

Once the get property function 64 is complete, the allocated memory 
location contains a zero (false) or one (true) result. The next operation 
(diamond 206) tests the value of the property 116. If true, the property get 
function 64 is once again invoked (block 204). 

If the property 116 is false, however, the get property function 64 is 
invoked, this time with the bus device count property 115 passed as a parameter 
(block 208). The bus device count property 115 indicates to the RAID software 
12a how many devices were found on the SCSI bus llOA as a result of the 
scanning operation. Accordingly, an integer value is stored in the bus device 
count memory location once the property is retrieved by the get property 
function 64. The scanning operation is thus complete (block 210). 

Thus, an interface to hardware includes a configuration library and objects 
to model the hardware. Software programs using the interface need not 
understand how to communicate with the hardware. Instead, the software 
programs may communicate with the interface. In turn, the interface 
communicates with the hardware. Such an organization allows the software to 
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be written even before the hardware is implemented, prior to the addition of new 
or different hardware, or under other conditions in which the hardware 
requirements are unknown. 

While the present invention has been described with respect to a limited 
number of embodiments, those sl<illed in the art will appreciate numerous 
modifications and variations therefrom. It is intended that the appended claims 
cover all such modifications and variations as fall within the true spirit and scope 
of this present invention. 
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